The MDriven Server can be used to scale out to many Slave servers to swallow extreme loads of requests or it may be scaled out geographically to reduce latency for user clusters.

Setting up a slave server is easy. Read more here on setting up a History slave or on the purpose of the History Server.

Start by setting your master in mode Master and ensure you have the MDrivenServerSynk table in the database.

The MDrivenServerSynk table will hold the commit packages until they are truncated away by the MaxQueueLengthInDays Setting.

It is beneficial to have the server in Master mode even if you do not have any slaves since a MasterServer will load Refresh-data from MDrivenServerSynk. This means that your client refresh will not suffer from server restarts as it does otherwise (without MDrivenServerSynk, commit packages are held in memory only and will be lost on server restart - leaving a possibility for clients to not see other clients' changes when using refresh).

(There is always exactly 1 master in a cluster of MDriven Servers (You can have many clusters - 1 master each))

To get a new slave running, it is best to take a backup of your master DB and restore that as the slave DB. The Slave-logic of MDriven is then used to keep the slave up to date with the master after this point.

• In this example, the Master is in a DB called MtDev – and the slave will be in a database called MtDevSlave. The slave also needs the MDrivenServerSynk - so it is best to set up the master first, then backup, and restore to the slave.
• In this example, both databases reside on the same DB-server – this is however not smart if the aim was to reduce the load on the DB-server. The normal approach is to put slaves on separate machines - possibly far apart - close to a specific user cluster to reduce latency for data-read.

Once we have the MtDevSlave database in place, we set up an MDrivenServer that uses it.

Follow the instructions to set up MDriven Server.

We must set up the MtDevSlave MDriven Server to be a slave:

We must tell the slave who is master, and how we access it – user and password (Note: user and password are both case sensitive).

To get everything going, we need to have the first version of the model – this is the only time we need to think about the model for the slave. After this point, the slave will get the new model from the master if the master changes the model.

We can do this with this button named “Get model from master”:

The slave can run in 3 different modes:

ReadOnlySlave will accept write requests but will reroute these to the master – and the data will enter the slave via the MDrivenServerSynk mechanism in a short while.

ReadWriteSlave will accept write requests to local the slave. This is a somewhat strange mode – the slave can get a new state of its own – that may be overwritten by master changes.

HistorySlave will use the Master-model but before applying it to the slave, it will set each class to Versioned in the model. This instructs the framework to add timestamps to all data written and also makes the framework insert only new versions and never update existing versions on every data row in the DB.

HistorySlave creates a vault of all changes ever done from the start time to now. You can use special OCL operators like oclAtTime on this model and start the MDriven Designer prototype in History aware mode to access the data herein:

The HistorySlave has the same good side effects as following a CQRS pattern - all history is retained.